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The  Use  of  Representation  Clauses 
and  Implementation-Dependent  Features 

In  Ada: 

IVA.  Qualitative  Results  for  Ada/M(44) 

Version  1.6 

Abstract:  This  report,  one  in  a  series,  provides  a  qualitative  assessment  of  the  support  of 
representation  clauses  and  implementation-dependent  features  in  Ada  provided  by  the 
Ada/M(44)  compiler,  Verston  1.6.  The  evaluation  questions  that  were  presented  in  a  previ¬ 
ous  report  of  this  series  form  the  basis  of  the  (^alitative  assessment.  A  subjective  evalu¬ 
ation  of  the  support  provided  for  these  features  is  also  presented. 


1.  Introduction 

The  Ada  language  was  developed  as  a  general  purpose  language  applicable  to  the  development  and 
maintenance  of  mission-critical  systems  for  the  Department  of  Defense  (DoD).  In  the  development  of 
the  language,  a  need  to  allow  the  language  to  interact  with  the  underlying  machine  architecture  was 
recognized.  This  coupling  is  discussed  in  Chapter  13  of  the  Reference  Manual  for  the  Ada  Program¬ 
ming  Language  [i]. 

A  frequent  characteristic  of  mission-critical  systems  is  that  they  employ  "packed*  data  structures. 
Furthermore,  within  such  packed  structures  there  may  be  nonstandard  data  representations.  For 
example,  an  integer  type  may  have  a  length  of  12  bits,  or  some  fixed-point  type  may  have  arbitrarily 
scaled  precision. 

Such  packed  data  structures  are  defined  in  Ada  through  the  use  of  representation  clauses.  The  use 
of  these  clauses  is  highly  machine  dependent.  TTiat  te,  some  compilers  may  provide  only  limited 
support,  while  others  may  provide  a  full  set  of  capabilities.  Since  representation  clauses  are  imple¬ 
mentation  dependent,  their  use  may  affect  the  portability  of  any  code  which  uses  these  features. 

This  report  is  one  of  a  series  of  reports  related  to  the  use  of  representation  clauses  and 
implementation-dependent  features  in  Ada.  The  first  report  in  the  series,  reference  [2],  provides  an 
overview  of  the  use  of  representation  clauses  and  implementation-dependent  features  and  contains  a 
series  of  case  study  examples.  A  second  report,  reference  [3],  fomnulated  a  list  of  questions  ap¬ 
plicable  to  the  evaluation  of  a  particular  compiler  from  the  perspective  of  representation  clauses  and 
implementation-dependent  features.  This  is  followed  by  a  discussion  of  experimental  procedures  and 
methodologies,  in  reference  [4].  Finally,  in  reference  {5],  a  qualitative  assessment  of  the  support 
provided  for  representation  clauses  and  implementation-dependent  features  for  the  Vax  Ada  compiler 
was  performed. 

The  purpose  of  this  report  is  to  provide  a  qualitative  assessment  of  the  support  of  representation 
clauses  and  implementation-dependent  features  in  Ada  provided  by  the  Ada/M(44)  compiler.  Thus, 
the  questions  raised  in  reference  [3]  are  answered  here;  the  emphasis  is  principally  qualitative. 
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The  decision  to  assess  the  Ada/M(44)  compiler  was  motivated  by  the  following  reasons.  First,  the 
development  of  this  compiler  is  funded  by  the  Navy.  This  development  is  coupled  to  the  Ada  Lan¬ 
guage  System  (ALS)  which  was  originally  funded  by  the  Army.  Second,  the  Ada/M(44)  targets  to  the 
AN/UYK-44,  which  is  a  Navy  standard  processor.  Thus,  the  results  reported  here  are  expected  to  be 
of  interest  to  applications  that  use  the  Ada/M(44)  compiler. 

This  report  is  organized  in  the  following  manner.  In  Chapter  2  we  present  a  discussion  of  the  qualita¬ 
tive  results  applicable  to  the  use  of  representation  clauses  and  implementation-dependent  features 
for  the  Ada/M(44)  compiler.  As  in  reference  [5],  a  generalized  subjective  assessment  based  on  the 
detailed  results  is  also  given.  In  Chapter  3.  the  relation  between  the  results  obtained  and  the  ex¬ 
amples  presented  in  reference  [2]  is  discussed.  This  discussion  illustrates  the  use  of  qualitative 
results,  such  as  reported  here,  for  application-specific  problems.  A  brief  summary  appears  in  Chapter 
4,  followed  by  a  list  of  the  applicable  references.  The  actual  results,  which  are  answers  to  specKic 
questions,  are  provided  in  Appendix  I. 

This  report  has  been  prepared  by  the  Ada  Embedded  Systems  Testbed  Project  at  the  Software 
Engineering  Institute  (SEI).  The  SEI  is  a  federally  funded  research  and  development  center  (FFRDC) 
sponsored  by  the  Department  of  Defense  (DoD)  and  established  and  operated  by  Carnegie  Mellon 
University.  This  report  was  prepared  while  the  authors  were  on  sabbatical  leave  at  the  SEI. 
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2.  Discussion 


A  basic  goal  of  reference  [3]  was  to  define  a  set  of  questions  relevant  to  the  assessment  of  a  partic¬ 
ular  compiler  from  the  perspective  of  representation  clauses  and  implementation-dependent  features. 
The  questions  appearing  in  reference  [3]  are  of  a  qualitative  nature,  as  well  as  quantitative.  Refer¬ 
ence  [5]  shows  the  application  of  that  set  of  questions  for  the  purpose  of  qualitatively  assessing  the 
support  provided  for  representation  clauses  and  implementation-dependent  features  for  the  Vax  Ada 
compiler. 

It  is  the  purpose  of  this  Section  to  provide  a  response  to  the  questions  posed  in  reference  [3]  for  the 
Ada/M(44)  compiler  in  the  same  manner  as  was  presented  in  reference  [5]  for  Vax  Ada.  As  the 
emphasis  here  is  toward  a  qualitative  level  of  assessment,  the  reported  results  emphasize  this  aspect 
of  evaluation.  In  other  words,  the  focus  in  this  report  is  on  whether  a  particular  aspect  of  represen¬ 
tation  clauses  and  implementation-dependent  features  is  supported,  as  well  as  the  anx>unt  of  sup¬ 
port.  Questions  which  are  principally  quantitative  in  nature  may  be  evaluated  according  to  the  meth¬ 
odology  described  in  reference  [4]  and  will  not  be  addressed  here.  Thus,  no  attempt  to  evaluate 
compiler  performance  is  made  in  this  report.  In  spite  of  this,  it  is  believed  that  dissemination  of  these 
results  is  warranted  and  are  of  interest  to  the  application  development  community. 

The  responses  to  the  questions  have  been  obtained  from  consideration  of  the  applicable  documen¬ 
tation,  as  well  as  examination  of  selected  generated  code.  The  particular  version  of  the  Ada/M(44) 
compiler  which  was  used  for  this  assessment  was  Version  1.6.  The  questions  and  answers  are 
presented  in  Appendix  I.  In  the  responses,  we  have  attempted  to  cite  the  document  that  provided  the 
required  information.  The  particular  documents  are  cited  in  the  following  manner: 

1 .  PSEH  ■  Ada/M(44)  Program  Support  Environment  (PSE)  Handbook  (6] 

2.  RTEH  «  Ada/M(44)  Run-Time  Environment  Handbook  [7] 

3.  DN  >  Ada/M(44)  Delivery  Notes  ADAM  [6] 

4.  TD  =  ANAJYK-44  Technical  Description  [9] 

Some  of  the  questions  appearing  in  Appendix  I  can  only  be  answered  by  detailed  assessment,  and 
such  questions  have  been  so  indicated.  The  detailed  assessment  requires  quantitative  procedures 
such  as  those  described  in  reference  [4].  For  our  purposes,  the  term  quantitative  is  used  in  a  broad 
sense  in  that  it  refers  to  performance  issues  and  measurements  and  also  to  detailed  examination  of 
generated  code  to  extract  information  about  the  internals  of  the  compiler. 

Although  the  responses  presented  in  Appendix  I  are  cast  in  qualitative  terms,  it  is  quite  evident  that 
there  is  a  considerable  amount  of  information  available.  It  is  recognized  that  many  users  will  desire 
an  overview  of  the  support  provided  for  representation  clauses  and  implemerrtation-dependent  fea¬ 
tures.  Thus,  in  reference  [5],  a  set  of  subjective  criteria  was  discussed  from  which  support  of  the 
major  aspects  of  representation  clauses  and  implementation-dependent  features  may  be  assessed. 
The  set  of  subjective  criteria  is  the  following: 

1.  Full  Support:  The  compiler  provides  support  for  the  language  feature,  subject  to  natu¬ 
ral  limitations  imposed  on  the  hardware  implementation. 
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2.  Support  wtth  Minor  Limitations:  The  compiler  provides  support  for  the  language  fea¬ 
ture  subject  to  only  minor  limitations.  This  implies,  then,  that  the  support  provided 
should  be  satisfactory  for  many  applications. 

3.  Support  with  Major  Limitations:  The  compiler  provides  support  for  the  language  fea¬ 
ture  but  there  are  major  limitations.  This  should  be  understood  to  mean  that  use  of  the 
indicated  language  feature  in  many  applications  would  be  difficult. 

4.  Unsupported:  The  compiler  provides  no  support  for  the  language  feature. 

We  stress  that  the  criteria  iisted  above  are  subjective  in  nature.  There  may  be  cases  where  a 
particular  category  is  supifMrted  with  only  minor  limitations.  It  may  be,  however,  that  the  minor  limita¬ 
tions  could  cause  a  serious  problem  for  some  ajsplications.  In  spite  of  the  caveat  about  the  subjective 
nature  of  the  judgments  to  be  p>resented,  nevertheless,  we  believe  they  have  merit. 

The  results  presented  are  basically  organized  in  correspondence  with  the  categories  appearing  in 
Ap)p)endix  I.  One  category  not  present  in  Ap)pendix  I  yet  deemed  sufficiently  important  enough  to 
include  in  this  subjective  evaluation  is  that  of  support  facilities.  We  are  referring  specifically  to  docu¬ 
mentation  and  debugging  fadlities.  Below,  each  category  title  is  given,  followed  by  the  subjective 
rating.  The  rating  is  then  followed  by  explanafory  information  where  it  is  deemed  especially  relevant. 

1.  Pragma  OPTIMIZE:  Full  Support. 

2.  Data  Types  Supported:  Supported  with  Minor  Limitations.  The  lack  of  support  for 
floating-point  types  with  precision  greater  than  six  (decimal)  digits  may  cause  problems 
for  some  applications. 

3.  Pragma  PACK:  Full  Support. 

4.  Length  Clauses:  Supported  with  Minor  Limitations.  It  is  required  that  fixed-point  types 
be  represented  according  to  a  constant  size.  This  could  present  problems  for  certain 
applications. 

5.  Enumeration  Representation  Clauses:  Full  Support. 

6.  Record  Representation  Clauses:  Supported  with  Minor  Limitations.  Where  a  record 
contains  a  component  of  a  fixed-point  type,  restrictions  on  the  size  of  the  component 
may  be  a  problem  due  to  the  limitations  imposed  by  the  compiler. 

7.  Address  Clauses:  Supported  with  Major  Limitations.  Address  clauses  are  not  sup¬ 
ported  for  objects. 

8.  Data  Conversion  and  Assignment:  Full  Support. 

9.  Representation  Attributes:  Full  Support.  Ada/M(44)  provides  an  additional  attribute 
which  allows  the  user  to  access  physical  addresses  and  may  be  helpful  for  some  sys¬ 
tems. 

10.  Pragma  INTERFACE:  Supported  with  Major  Limitations.  Only  subprograms  written  in 
assembler  may  be  specified. 

1 1 .  Support  Facilities:  Supported  with  Major  Limitations.  No  symbolic  debugger  is  cur¬ 
rently  available  for  the  AN/UYK-44  target.  AddKionally,  the  documentation  does  not 
provide  as  much  information  as  a  user  would  perhaps  require.  For  example,  in  the 
Ada/M(44)  references  [6]  through  [9],  there  is  no  Appendix  F.  Appendix  F  lists  the 
implementation-dependent  characteristics.  As  another  example,  the  Reference  Manual 
for  the  Ada  Programming  Language  states  that  whether  or  not  a  record  component  can 
overlap  a  storage  boundary  is  implementation-defined.  The  Ada/M(44)  references  do 
not  specify  whether  or  not  storage  boundary  overlaps  are  allowed. 
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From  the  preceding  summary,  it  is  evident  that  the  support  for  representation  ciauses  and 
implementation-dependent  features  by  Ada/M(44)  has  considerabie  variation.  In  some  cases,  there 
is  more  support  than  required  by  the  language,  such  as  representation  attributes,  in  other  cases, 
notably  address  clauses,  there  is  only  minimal  support  provided  or,  as  with  length  clauses,  the  sup¬ 
port  provided  has  restrictions  as  to  details  of  implementations.  The  preceding  illustrates  two  points. 
First,  the  results  presented  here  senre  to  illustrate  the  compiler-dependent  aspects  of  support  pro¬ 
vided  for  representation  clauses  and  implementation-dependent  features.  A  second  point  -  and  of 
possibly  greater  significance  to  application  developers  -  is  that  the  selection  and  use  of  a  particular 
compiler  must  be  made  with  extreme  care. 


It  must  be  stressed  that  the  results  presented  in  this  report  are  of  a  qualitative  nature.  As  such,  they 
describe  the  support  for  a  particular  aspect  of  representation  clauses  and  implementation-dependent 
features.  The  issue  of  support  for  a  language  feature  is  clearly  different  from  either  the  performance 
of  the  compiler  or  the  assessment  of  the  effect  of  use  of  the  feature.  Issues  of  the  latter  type  are 
principally  quantitative  in  nature. 
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3.  Relation  to  Examples  in  Volume  I 

In  the  preceding  chapter,  we  presented  a  synopsis  of  the  support  provided  by  the  Ada/M(44)  compiler 
for  representation  clauses  and  implementation-dependent  features.  The  synopsis  abstracted  some 
general  results  from  the  detailed  answers. 

It  may  be  well,  however,  to  consider  the  manner  in  which  a  report  such  as  this  would  be  used  by 
application  developers.  This  is  clearly  an  important  issue  and  is  now  demonstrated.  Thus,  in  the  first 
volume  of  this  series,  reference  [2],  a  number  of  case  study  examples  were  presented.  Those  ex¬ 
amples  were  drawn  from  the  mission-critical  systems  community  and  contain  certain  characteristics 
representative  of  problems  typically  encountered. 

In  the  following,  a  brief  statement  of  the  problem  for  each  example  in  reference  [2]  is  presented.  The 
implementation  of  the  particular  example  is  then  considered,  based  on  the  Ada/M(44)  compiler  which 
is  targeted  for  the  AN/UYK-44.  The  ability  to  affect  a  solution  to  the  stated  problem  is  presented.  The 
discussion  is  based  on  the  results  presented  in  Appendix  I.  That  is,  we  provide  specific  references  to 
the  questions  (and  answers)  deemed  relevant  for  the  example  under  consideration.  It  is  believed  that 
such  a  procedure  illustrates  the  manner  in  which  a  report  such  as  this  may  be  used  by  application 
developers. 

In  the  following  paragraphs,  references  are  made  to  the  questions  and  answers  appearing  in  Appen¬ 
dix  I.  Questions  and  answers  are  referenced  by  category  letter  followed  by  the  number  of  the  ques¬ 
tion.  For  example,  "F.a*  refers  to  question  3  under  category  F,  which  is  Record  Representation 
Clauses. 

In  Section  5.2  of  the  first  report  in  this  series,  reference  [2],  an  introductory  example  was  given 
illustrating  the  use  of  representation  clauses.  The  example  was  that  of  a  message  header  that 
appears  in  every  message  used  for  communications  between  a  shipboard  Inertial  Navigation  System 
(INS)  and  some  external  computer  (EC).  This  example  illustrates  the  length,  enumeration,  and 
record  clauses,  with  data  of  type  integer  and  enumeration.  The  assumed  value  of 
SYSTEM.STORAGE_UNIT  for  the  examples  is  equal  to  8  and  the  default  value  for  Ada/M(44)  is  16. 
Thus,  this  implementation  would  be  invalid  for  Ada/M(44).  Though,  as  stated  in  J.4.  pragma 
STORAGE_UNIT  is  supported  and  can  be  used  to  change  Ada/M(44)  SYSTEM.STORAGE_UNIT  to 
8  for  these  examples.  With  the  inclusion  of  pragma  STORAGE_UNIT,  this  example  would  be  legal 
for  Ada/M(44)  since  the  requirements  for  this  example  are  within  the  following  restrictions; 

1.  The  size  specified  in  a  length  clause  for  an  integer  type  must  not  exceed  16  bits  (as 
stated  in  D.2). 

2.  The  storage  specified  in  a  component  clause  must  be  enough  to  hold  any  value  of  the 
component  type  (as  noted  in  F.3). 

3.  Record  components  are  allowed  to  overlap  storage  unit  boundaries  (see  F.4). 

A  note  should  be  made  that  as  stated  in  A.2,  Ada/M(44)  ordering  of  bits  and  storage  units  is  right  to 
left,  arxl  these  examples  use  left  to  right  ordering.  Thus,  when  examining  the  actual  contents  of 
memory,  the  results  will  be  different  from  that  expected.  If  right  to  left  ordering  is  required,  say  by 
some  external  system,  then  these  examples  will  not  be  valid  for  Ada/M(44). 
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The  second  example,  given  in  Section  5.3  o(  reference  (2],  is  that  of  a  Test  Message  which  is  used  to 
test  the  communications  interface  between  the  INS  and  EC.  This  example  contains  a  message 
header  (implemented  in  the  previous  example)  and  integer  test  data.  As  in  the  last  example,  the 
requirements  here  are  within  the  restrictions  listed  in  F.3  that  the  storage  specified  in  the  component 
clause  must  be  enough  to  hold  any  value  of  the  component  type,  and  in  F.4  that  storage  unit  bound¬ 
ary  overlaps  are  allowed.  Also,  the  implementation  of  this  example,  and  some  of  the  examples  to 
follow,  use  a  predefined  type  INTEGER  which  is  assumed  to  be  32  bits.  Ada/M(44)  predefined  type 
INTEGER  is  16  bits,  as  seen  in  B.1.  Note  also  in  B.1  that  there  is  another  pre-defined  type. 
LONGJNTEGER,  which  is  32  bits.  Therefore,  with  the  inclusion  of  pragma  STORAGE_UNIT  and 
replacing  type  INTEGER  with  LONG_INTEGER,  this  implementation  would  be  valid  for  Ada/M(44). 

The  next  example,  in  Section  5.4  of  reference  [2],  is  slightly  nrwre  complicated  than  the  previous 
examples  in  that  it  contains  both  fixed-  and  floating-point  data.  A  navigation  message  is  the  example, 
and  it  is  used  to  send  data  such  as  ownship  latitude,  longitude,  and  speed  to  an  EC.  This  example 
contains  a  requirement  that  fixed-point  data  be  represented  in  less  than  32  bits.  Ada/M(44) 
represents  fixed-point  types  in  32  bits  as  discussed  in  B.2.  Based  on  this  and  the  restriction  listed  in 
F.3  that  a  component  clause  must  specify  enough  storage  to  hold  any  value  of  the  component  type, 
this  implementation  is  illegal  for  Ada/M(44).  To  implement  this  example  using  Ada/M(44),  a  conver¬ 
sion  routine  must  be  considered  that  converts  the  actual  data  field  in  the  message  to  the  default 
Ada/M(44)  32-bit  fixed-point  representation.  This  will  be  the  representation  from  which  calculations 
are  performed. 

The  fourth  example.  Section  5.5  of  reference  [2],  illustrates  an  implementation  of  analog  conversion. 
In  this  example,  ship  heading,  roll,  and  speed  data  are  DMA  mapped  to  particular  addresses  and 
must  be  converted  into  actual  values.  The  requirement  that  data  are  DMA  mapped  was  met  by  the 
use  of  address  clauses.  This  example  would  not  be  valid  on  Ada/M(44)  since,  as  stated  in  G.l, 
address  clauses  for  objects  are  not  supported. 

In  Section  5.6  of  reference  [2],  an  example  of  a  message  checksum  was  given.  This  function  com¬ 
putes  the  checksum  of  the  navigation  message  that  was  implemented  in  Section  5.4  of  reference  [2] 
and  discussed  above.  Recall  that  the  implementation  of  the  navigation  message  was  invalid  for 
Ada/M(44).  Thus,  this  checksum  implementation  would  be  invalid  sirrce  it  depends  on  that  message 
implementation.  A  general-purpose  checksum  routine  based  on  the  use  of  the  generic  function 
UNCHECKED_CONVERSION  and  dealing  with  valid  message  implementations  would  be  legal  tor 
Ada/M(44)  since  the  following  restrictions  are  met; 

1 .  The  size  specified  for  an  integer  type  must  not  exceed  16  bits  (as  staled  in  D.2). 

2.  Ada/M(44)  supports  UNCHECKED_CONVERSION  (reported  in  H.3). 

3.  The  size  of  the  source  arvj  target  objects  used  by  an  instantiation  of 
UNCHECKED_CONVERSION  must  be  equal  (as  stated  in  H.4). 

Also,  as  previously  noted,  type  INTEGER  must  be  replaced  with  l.ONG_INTEGER. 

The  final  example  given  in  reference  (2).  Section  6.4.2,  illustrates  the  use  of  pragma  INTERFACE. 
The  problem  in  fhis  example  is  the  need  to  allocate  and  access  some  data  structure  containing  data 
and  status  information  tor  an  INS  gyro.  As  part  of  this  problem,  a  conversion  must  be  performed  to 
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obtain  a  32-bit,  fixed-point  quantity  that  has  15  bits  of  precision  from  arbitrary  fixed-point  quantities. 
This  conversion  was  performed  by  an  assembler  routine  that  is  accessed  via  pragma  INTERFACE 
with  representation  attributes  providing  the  appropriate  parameters  to  that  routine.  This  example  is 
compilable  on  Ada/M(44)  with  the  following  providing  relevant  information  to  verify  this: 

1.  There  are  no  restrictions  on  the  use  of  'ADDRESS  (see  1.1). 

2.  There  are  no  restrictions  on  the  use  of  'FIRST_BIT  (see  1.4). 

3.  There  are  no  restrictions  on  the  use  of  'LAST_BIT  (see  1.5). 

4.  Pragma  INTERFACE  is  supported,  though  the  language  name  is  restricted  to 
MACROM_NORMAL  which  is  the  AN/UYK-44  assembler  (see  J.5). 


The  preceding  has  illustrated  the  use  of  results  presented  in  this  report  to  assess  problems  that  are 
representative  of  mission-critical  systems.  The  purpose  in  presenting  the  above  discussion,  there¬ 
fore,  is  to  illustrate  how  reports  such  as  this  may  be  used.  It  is  to  be  noted  that  the  emphasis  in  the 
above  discussion  has  been  on  application  of  qualitative  results.  That  is,  the  emphasis  is  more  toward 
obtaining  a  solution  to  a  problem,  as  opposed  to  an  assessment  of  how  "well"  the  solution  imple¬ 
ments  the  problem  requirement. 
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4.  Summary 

This  report  is  one  of  a  series  deaiing  with  the  use  of  representation  clauses  and  implementation- 
dependent  features  in  Ada.  This  report  provides  a  qualitative  assessment  of  the  Ada/M(44)  compiler, 
Version  Release  1.6.  Subjective  criteria  were  established  to  provide  an  overall  assessment  of  the 
support  provided  by  this  compiler  for  representation  clauses  and  implementation-dependent  features. 
In  general  and  based  upon  those  subjective  criteria,  this  compiler  provides  support  with  minor  limita¬ 
tions  for  the  implementation  of  representation  clauses  and  implementation-dependent  features. 
Some  exceptions,  however,  have  been  noted. 

This  report  may  be  used  in  conjunction  with  the  results  of  a  detailed  experimental  assessment  of  the 
Ada/M(44)  compiler  to  determine  its  characteristics  for  use  by  specif  ic  applications. 
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Appendix  I:  Questions  Reievant  to  the  Use  of 
Representation  Ciauses  and  Impiementation-Dependent 
Features 

A.  General: 

1 .  What  Is  tho  basic  unit  of  SYSTEM.STORAGE_UNIT7  (This  Is  useful  when  defining  record 
layouts.) 

One  word  or  16  bits.  [PSEH,  page  7-7] 

2.  What  Is  the  ordering  of  allocation  for  storage  units?  Is  It  left-to-rlght  or  right-to-left  with 
respect  to  each  other?  How  are  bKs  rtumbered  within  storage  units?  Is  it  left-to-rlght  or 
rtght-to-left?  Does  the  numbering  always  begin  wHh  zero?  (This  Is  useful  when  defining 
record  layouts  and  verifying  the  actual  allocation  of  record  layouts.) 

Bits  within  storage  units  are  numbered  0  ..  15  starting  at  the  right.  [PSEH,  page  7-i  1]  The  ordering  of 
storage  units  with  respect  to  each  other  is  right  to  left. 

3.  It  Is  also  appropriate  to  consider  the  role  of  the  underlying  architecture,  particularly 
regarding  data  conversions  from  representation  ciauses  to  other  formats.  Does  the  machine 
Include  Instructions  tor  inserting  and  extracting  bit-length  fields?  What  are  the  restrictions  on 
the  use  of  such  Instructions  (for  example,  what  is  the  maximum  field  size  to  which  an  instruc¬ 
tion  may  be  applied)? 

In  the  current  instmction  set  for  ANAJYK-44,  there  are  no  instructions  that  support  arbitrary  bit  length 
insertion  and  extraction.  Samples  of  machine  code  generated  for  AN/UYK-44  showed  that  calls  were 
generated  to  the  njntime  Ibrary  to  perform  general  purpose  bit  operations,  e  g.  bit  move.  There  are. 
however,  instructions  to  perform  masked  substitution  of  bit  fields  but  these  instorctions  are  restricted 
to  corresponding  bit  fields. 

It  is  interesting  to  note  that  the  instruction  set  also  supports  basic  mathematical  functions,  e  g  . 
square  root,  sine,  arcsine,  in  hardware. 

(TD) 

4.  It  pragma  OPTIMIZE  supported?  If  to,  are  there  any  restrictions  on  Its  use? 

Yes.  The  default  argument  is  SPACE  and  the  OPTIMIZE  option  must  be  given  to  the  compiler  for  this 
pragma  to  be  in  effect.  [PSEH,  page  7-3] 

5.  The  use  of  representation  clauses  may  present  unusual  problems  throughout  design  and 
coding.  What  facilities  exist  for  verifying  results  when  representation  clauses  are  used?  We 
are  speaking  here  of  the  debugger;  thus,  are  there  restrictions  on  the  use  of  the  debugger 
when  representation  clauses  are  used? 
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The  DEBUG  option  to  the  compiler  is  not  supported  for  Ada/M(44).  Thus,  currently  there  are  no 
symtx)lic  debugging  facilities  with  Ada/M(44).  [PSEH,  page  9-4] 

It  should  be  noted  that  there  are  other  facilities,  namely  MTASS,  for  simulation  and/or  debugging  of 
object  code  for  the  AN/UYK-44. 

6.  Does  the  compiler  provide  a  load  map  that  comalns  sufficient  details  to  Identify  the  loca¬ 
tion  of  quantities  specified  using  representation  clauses? 

Neither  the  Ada/M(44)  contpiler  nor  linker  provides  an  option  for  a  load  map  with  physical  location  of 
program  variabf  o.  (PSEH,  page  9-3  and  page  11-5] 

7.  Are  there  any  restrictions  on  representation  clauses? 

There  are  no  documented  restrictions. 

8.  Compiler  Implementors  currently  have  the  option  as  to  what  degree,  If  any,  the  features  In 
Chapter  13  of  the  Reference  Manual  for  the  Ada  Programming  Language  will  be  supported.  It  is 
conceivable  that  upgraded  versions  of  an  Implementation  will  enhance  the  support  originally 
available  for  such  features  as  representation  clauses.  How  Is  the  documentation  upgraded? 
Is  it  by  release  notes  or  page  changes?  The  manner  In  which  this  is  accomplished  can  affect 
the  ease  with  which  documentation  can  be  used. 

The  principal  documents  referenced  by  us,  namely  references  (6]  and  [7],  are  final  deliveries  on  the 
contract.  We  are  not  aware  of  change  pages  or  release  notes  to  the  above  documents.  It  is  not 
known  at  this  time  the  mechanism  by  which  documentation  will  be  upgraded.  A  set  of  delivery  notes, 
reference  [8],  accompanied  the  documentation  received  and  listed  known  problems  in  the  software. 


B.  Data  Types  Supported: 


1.  What  ara  the  basic  Implementations  of  integer  types? 

Ada/M(44)  offers  the  following  two  Integer  types; 

•  INTEGER  with  range  -2‘*(15) ..  2‘*(15)-1 

•  LONGJNTEGER  with  range  -2‘*(31) ..  2**(31)-1 

(PSEH,  page  7-6] 

Type  INTEGER  is  stored  as  a  word,  which  is  16  bits.  Type  LONGJNTEGER  is  stored  as  a  pair  of 
words,  where  the  most  significant  portion  of  the  object  is  stored  at  the  even  word  address  and  the 
least  significant  portion  of  the  object  is  stored  at  the  next  odd  address.  [PSEH,  page  8-2] 

2.  What  are  the  basic  Implementations  of  fixed-point  types? 

Each  fixed-point  type  is  stored  as  a  right  justified  integer  within  32  bits  and  with  an  implicit  scale 
factor.  [PSEH.  page  8-3] 

3.  What  are  the  basic  Implementations  of  floatlng-poim  types? 

Ada/M(44)  offers  one  floating-point  type: 

FLOAT  with  precision  of  6  digits  in  the  range 
-7.237005E75 ..  7.237005E75. 

[PSEH,  page  7-6] 

Type  FLOAT  is  stored  as  two  longword-aligned  addresses.  Longwofd-aligned  means  that  the  least 
significant  bit  of  the  first  word  of  the  object  must  be  bit  0  of  an  even  memory  address.  [PSEH,  page 
8-3] 

4.  Does  the  compiler  provide  predefined  unsigned  data  types?  If  not.  Is  It  permissible  for  a 
user  to  define  these  types?  For  example,  Is  the  following  legal: 

type  Llnsigned_SmallJnt  Is  range  0 ..  7; 
for  Unsigned_SmallJnt'SIZE  use  3; 

Ada/M(44)  does  not  provide  any  unsigned  data  types  though  the  example  above  compiles  without 
error.  Thus,  it  is  permissible  to  define  unsigned  integer  types  that  are  less  than  or  equal  to  16  bits 
since  the  largest  value  allowed  for  the  size  specified  in  a  length  clause  for  an  integer  is  16.  (See 


C.  Pragma  PACK: 

1 .  Does  the  compiler  support  the  use  of  pragma  PACK? 

Yes.  IPSEH,  page  7-3] 

2.  What  restrictions  are  placed  on  the  use  of  pragma  PACK?  For  example,  are  there  certain 
types  that  may  or  may  not  be  packed? 

There  ate  rx)  documented  restrictions  on  the  use  of  this  pragma.  [PSEH,  page  7-3] 

When  pragma  PACK  is  in  effect,  the  compiler  does  not  Oi/erride  the  default  size  of  an  integer  or 
enumeration  type,  unless  a  length  clause  is  given.  If  a  length  clause  is  given,  the  smaller  size  o* 
either  the  default  size  or  the  size  specified  in  the  clause  is  used.  (PSEH,  page  8-2] 
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D.  Length  Clauses: 


1 .  Does  the  compiler  support  the  use  of  length  clauses?  What  are  the  restrictions  on  their 
use? 

Yes.  [PSEH,  page  7-8]  There  are  no  documented  restrictions. 

2.  Are  there  restrictions  on  the  use  of  the  SIZE  attribute  designator  in  a  length  clause? 

The  following  restrictions  exist: 

•  For  integer  types  specified  with  range  L  ..  R  the  size,  n,  specified  must  be  such  that; 

•  2  s  n  5 16  where  R  s  2"'’-1  and  L  i  -2"'^ 

•  1  <  n  s  15  where  R  ^  2"'^  and  L  s  0 

By  default,  a  size  16  is  used  when  R  <  2^5-1  arxl  L  ^  -2^®;  otherwise,  a  size  of  32  is 
used. 

•  For  fixed-point  types,  the  size  specified  can  only  be  32. 

•  For  ffoating-point  types,  the  size  specified  can  only  be  32. 

•  For  enumeration  types,  the  size,  n,  SF>ecified  must  be  such  that; 

•  2  s  n  s  16  where  'FIRST  and  'LAST  both  fall  within  the  range  -2^® ..  2^®-1 

•  1  <  n  s  15  where  'FIRST  s  0  and  'LAST  5  2<’S'2E>-1 

The  default  size  is  16. 

•  For  arrays  and  records,  the  size  specified  must  be  less  than  or  equal  to  23’-l .  [PSEH, 

7-11] 

[PSEH,  page  7-8] 

3.  Are  there  restrictions  on  the  use  of  the  STORAGE_SIZE  attribute  designator  In  a  length 
clause? 

There  are  no  documented  restrictions. 

4.  Are  there  restrictions  on  the  use  of  the  SMALL  attribute  designator  In  a  length  clause? 
There  are  no  documented  restrictions. 

5.  When  using  a  SIZE  attribute  designator  in  a  length  clause  the  Reference  Manual  for  the 
Ada  Programmirtg  Language  states  that  the  value  of  the  expression  specifies  an  upper  bound 
(or  the  number  of  bits  to  be  allocated.  The  presence  of  a  range  constraint  or  the  use  of  a 
predefined  type  implicitly  defines  the  maximum  number  of  bits  required  to  allocate  objects.  If 
extra  bits  are  specified  in  the  length  clause,  are  these  extra  bits  allocated  by  the  compiler? 

With  the  available  documentation  and  the  absence  of  a  facility  that  provides  a  load  map.  we  were 
unable  to  resolve  the  issue  raised  above.  Due  to  this  fact,  detailed  experimentation  is  required  for 
resolution  of  this  issue. 
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6.  Suppose  a  type,  wtth  associated  length  clause,  has  been  specified  storage  where  the 
number  of  bits  Is  not  sufficient  to  store  the  specified  range  of  values.  For  example,  suppose 
an  Integer  type  with  range  10  ..  13  is  defined,  and  three  bits  of  storage  are  allocated  for  that 
type.  Is  an  error  generated  for  this  case?  If  no  error  Is  generated  by  the  compiler,  how  is  a 
case  such  as  this  treated? 

The  following  was  compiled  and  an  error  stating  ’not  sufficient  storage’  was  received: 

type  Intis  range  10 ..  13; 
for  Int'SIZE  use  3; 

7.  What  impact  does  the  length  clause  have  on  the  packing  algorithm  of  composite  types? 
Detailed  experimentation  is  required  for  resolution  of  this. 

8.  What  is  the  effect  of  pragma  OPTIMIZE  (TIME)  on  storage  allocation  when  length  clauses 
are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 

9.  What  Is  the  effect  of  pragma  OPTIMIZE  (SPACE)  on  storage  allocation  when  length 
clauses  are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 

10.  What  Is  the  effect  of  pragma  PACK  on  storage  allocation  when  length  clauses  are  used? 
Detailed  experimentation  is  required  for  resolution  of  this. 
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E.  Enumeration  Representation  Ciauses: 

1 .  Does  the  compiler  support  the  use  of  enumeration  representation  clauses?  What  are  the 
restrictions  on  their  use? 

Yes.  [PSEH,  page  7-8]  There  are  rx)  documented  restrictions.  Preliminary  tests  show  negative  code 
values  are  allowed. 

2.  Consider  an  enumeration  type  and  associated  enumeration  representation  clause  where 
the  enumerated  values  specified  are  not  contiguous  integers,  such  as: 

type  Name  Is  (Name_i .  Name_2.  Name_3.  Name_4); 
lor  Name  use 

(  Name_1  =>  1.  Name_2  =>  5,  Name_3  =>  12,  Name_4  »>  163 ); 

The  enumeration  type  may  not  be  efficiently  Implemented  because  of  the  noncontiguous  na¬ 
ture  of  the  integers  specified  In  the  enumeration  representation  clause,  Illustrated  above. 
Hence,  how  are  enumeration  types  represented  internally,  particularly  in  the  case  where 
enumeration  clauses  are  specified  with  noncontiguous  values? 

Detailed  experimentation  is  required  for  resolution  of  this. 

3.  What  is  the  effect  of  pragma  PACK  on  storage  allocation  when  enumeration  represen¬ 
tation  ciauses  are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 

4.  What  is  the  effect  of  pragma  OPTIMIZE  (TIME)  on  storage  allocation  when  enumeration 
representation  clauses  are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 

5.  What  Is  the  effect  of  pragma  OPTIMIZE  (SPACE)  on  storage  allocation  when  enumeration 
represematlon  clauses  are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 
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F.  Record  Representation  Clauses: 

1.  Does  the  compiler  support  the  use  of  record  representation  clauses?  What  are  the 
restrictions  on  their  use? 

Yes.  [PSEH,  page  7-8]  There  are  no  documented  restrictions. 

2.  What  are  the  restrictions  on  the  use  of  the  alignment  clause  in  a  record  representation 
clause? 

The  only  values  allowed  for  alignments  are  1  and  2  (for  word  or  doubleword  alignment).  [PSEH,  page 
7-11] 

3.  What  are  the  restrictions  on  the  use  of  component  clauses  in  a  record  representation 
clause? 

A  component  clause  must  specify  enough  bits  to  hold  any  value  of  the  type  of  the  component  being 
allocated.  Components  of  the  following  types  cannot  be  specified  with  a  component  clause:  access, 
array,  record,  and  task.  [PSEH,  page  7-11] 

4.  Are  there  restrictions  on  the  overlap  of  record  components  with  respect  to  the  basic 
machine  storage  unit?  For  example,  If  a  machine  has  a  SYSTEM.STORAGE_UNIT  equal  to  16 
bits,  Is  It  permitted  to  have  components  of  a  record  that  are  larger  than  this  value? 

Preliminary  tests  showed  components  can  overlap  storage  unit  boundaries.  Thus,  components  can 
be  larger  than  16  bits,  which  is  SYSTEM,STORAGE_UNIT. 

5.  Consider  the  case  when  a  record  is  specified  with  a  record  representation  clause.  Where 
is  a  record  component  placed  which  has  no  associated  component  clause? 

Storage  is  first  allocated  to  those  components  that  have  component  clauses.  Following  this,  storage 
is  allocated  for  the  remaining  components  of  the  record  using  a  first-fit  algorithm.  In  particular,  if  there 
are  gaps  between  the  components  specified  with  a  component  clause,  the  storage  within  these  gaps 
is  allocated  by  a  first-fit  algorithm.  Note  that  the  use  of  the  a  first-fit  algorithm  as  indicated  above 
minimizes  total  storage  allocated  for  a  record. 

[PSEH,  page  8-5] 

6.  What  is  the  effect  of  pragma  OPTIMIZE  (TIME)  on  storage  allocation  when  record  repre¬ 
sentation  clauses  are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 

7.  What  Is  the  effect  of  pragma  OPTIMIZE  (SPACE)  on  storage  allocation  when  record  repre¬ 
sentation  clauses  are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 
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G.  Address  Clauses: 


1 .  Does  the  compiler  support  the  use  of  address  clauses?  What  are  the  restrictions  on  their 
use? 

Yes.  An  address  clause  is  only  allowed  for  a  single  task  entry.  An  address  clause  is  allowed  only 
within  a  task  specification  compiled  with  the  EXECUTIVE  compiler  option.  The  values  allowed  for  the 
simple  expression  in  an  address  clause  are  the  allowable  interrupt  entry  addresses  given  in  Apperxlix 
C,  of  reference  [7].  If  more  than  one  task  entry  is  eclated  to  the  same  address,  the  most  recently 
executed  entry  permanently  overrides  any  previous  entries.  [PSEH,  page  7-12] 

Note  that  programs  with  an  address  clause  specified  for  an  object  compile  and  link  without  error. 

2.  What  Is  the  type  SYSTEM.AOORESS? 

Type  SYSTEM.  ADDRESS  represents  virtual  addresses  in  the  range  0 

SYSTEM.MEMORY_SIZE-1.  [PSEH,  page  7-7] 

3.  What  is  the  effect  of  pragma  OPTIMIZE  (TIME)  on  storage  allocation  when  address 
clauses  are  used? 

Detailed  experimentation  is  required  for  resolution  of  this. 

4.  What  is  the  effect  of  pragma  OPTIMIZE  (SPACE)  on  storage  allocation  when  address 
clauses  are  used? 

Detailed  experimentation  is  required  for  resolution  ot  this. 

5.  Does  the  compiler  enforce  strong  typing  In  the  presence  of  address  clauses?  For  ex¬ 
ample,  Is  the  following  recognized  as  erroneous  by  the  compiler: 

fypeT_l  Is  range  0 ..  100; 

0_1  :T_1; 

forOj\  useaf  16#1000#; 

type  J_2  Is  digits  2  range  0.0  ..  100.0; 

0_2  :  T_2  ; 

for  0_2  use  af  1 6#1 000#; 

In  spite  of  the  fact  that  address  clauses  for  objects  are  not  supported,  this  example  (using  allowable 
addresses)  does  compile  without  error. 

6.  Does  the  compiler  or  linker  recognize  potential  conflicts  when  address  clauses  are  used? 
That  Is.  suppose  an  address  clause  Is  present  that  references  some  address,  say  X.  Assume 
that  the  address  X  Is  such  that  It  lies  within  the  address  space  of  generated  code.  How  is  this 
case  treated  by  the  compiler  and/or  linker? 

This  is  not  applicable  to  Ada/M(44)  since  the  only  allowabte  values  for  the  simple  expression  in  an 
address  clause  are  predefined  by  Ada/M(44).  Thus,  such  conflicts  will  not  occur. 
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H.  Data  Conversion  and  Assignment: 


1 .  How  is  conversion  accomplished  between  values  of  a  type  specified  by  the  default  repre¬ 
sentation  and  a  type  that  Is  specified  with  a  representation  clause?  (This  refers  to  the  use  of  a 
new  (derived)  type  that  Is  defined  in  terms  of  a  representation  clause.) 

Detailed  experimentation  is  required  for  resolution  of  this. 

2.  For  conversions  between  objects  of  different  types,  does  the  compiler  produce  in-line 
code  or  generate  a  call  to  a  library  routine  to  accomplish  the  conversion? 

Examination  of  generated  code  from  preliminary  tests  showed  the  following; 

•  when  converting  an  integer  vaiue  to  a  floating-point  vaiue,  the  integer  value  is  viewed  as 
a  fixed-point  value  and  the  AN/UYK-44  instruction,  FXC,  which  converts  fixed-point 
values  to  floating-point  values,  is  used 

•  when  converting  a  floating-point  value  to  an  integer  value,  a  call  was  made  to  a  run-time 
library  support  routine  to  affect  the  conversion 

The  AN/UYK-44  instruction  set  also  includes  an  instructton,  FLC,  which  converts  floating-point  values 
to  fixed-point  values. 


3.  Is  support  of  the  generic  function  UNCHECKED_CONVERSION  provided? 

Yes.  (PSEH,  page  7-12] 

4.  Are  there  any  restrictions  on  the  use  of  UNCHECKED_CONVERSION?  For  example,  are 
there  any  restrictions  on  the  source  and  target  types  for  UNCHECKED_CONVERSlON?  Do 
they  have  to  be  of  the  same  size? 

The  size  of  source  and  target  objects  must  be  the  same.  (PSEH,  page  7-1 2J 
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I.  Representation  Attributes: 


1.  What  are  the  restrictions  on  the  use  of  the  'ADDRESS  representation  attribute?  How 
does  the  compiier  interpret  the  use  of  this  attribute? 

There  are  no  documented  restrictions. 

2.  What  are  the  restrictions  on  the  use  of  the  'SIZE  representation  attribute?  How  does  the 
compiier  imerpret  the  use  of  this  attribute? 

There  are  no  documented  restrictions. 

3.  What  are  the  restrictions  on  the  use  of  the  'POSITION  representation  attribute  for  a  record 
component? 

There  are  no  documented  restrictions. 

4.  What  are  the  restrictions  on  the  use  of  the  'FiRST_BIT  representation  attribute  for  a 
record  component? 

There  are  no  documented  restrictions. 

5.  What  are  the  restrictions  on  the  use  of  the  'LAST_BIT  representation  attribute  for  a  record 
component? 

There  are  no  documented  restrictions. 

6.  What  Is  the  effect  of  pragma  OPTIMIZE  (TIME)  on  the  values  of  the  representation 
attributes? 

Detailed  experimentation  is  required  for  resolution  of  this. 

7.  What  is  the  effect  of  pragma  OPTIMIZE  (SPACE)  on  the  values  of  the  representation 
attributes? 

Detailed  experimentation  is  required  for  resolution  of  this. 
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J.  Miscellaneous: 


1 .  Suppose  an  object  has  been  allocated  storage  where  the  number  of  bits  Is  not  sufficient 
to  store  the  specified  range  of  values.  For  example,  suppose  an  object  has  been  allocated 
three  bits  of  storage,  but  Is  specified  to  be  In  the  range  10  through  13.  Is  an  error  generated 
for  this  case?  If  no  error  is  generated  by  the  compiler,  how  Is  a  case  such  as  this  treated? 

The  following  was  compiled  and  an  error  stating  "not  enough  storage  specified  for  Rec.B"  was 
received: 

type  Int  is  range  10  ..  13; 

type  Rec  is 
record 
A ;  Int; 

B :  Int; 
end  record; 

for  Rec  use 
record 

A  at  0  range  0  ..  3; 

B  at  0  range  4 ..  6; 
end  record; 

2.  Does  the  compiler  support  the  use  of  pragma  SUPPRESS? 

Yes.  [PSEH,  page  7-4] 

3.  What  restrictions  are  placed  on  the  use  of  pragma  SUPPRESS?  For  example,  can  every 
check  be  suppressed? 

The  following  restrictions  exist; 

•  suppression  of  OVERFLOW_CHECK  applies  only  to  integer  operations 

•  the  pragma  only  has  effect  within  the  compilation  unit  in  which  it  appears  except  if 
ELABORATION_CHECK  is  suppressed  which  applied  at  the  declaration  of  a  sub¬ 
program  or  task  unit  applies  to  all  calls  or  activations. 

[PSEH,  page  7-4] 

4.  is  pragma  STORAGE_UNIT  supported?  if  so,  are  there  any  restrictions  on  the  argument? 

Yes.  This  pragma  must  appear  at  the  start  of  the  first  compilation  when  creating  a  library.  [PSEH. 
page  7-3] 

5.  Is  pragma  INTERFACE  supported?  K  so,  are  there  any  restrictions  on  the  allowable 
forms  and  places  of  parameters  and  calls? 

Yes.  Pragma  INTERFACE  (argi,  arg2)  is  supported  where  the  first  argument  specifies  the  language 
and  is  restricted  to  the  value  MACROM_NORMAL.  The  second  argument  specifies  the  name  of  the 
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externally  supplied  subprogram.  Thus,  one  can  only  interface  to  assembler  language.  (PSEH,  page 
7-3] 

6.  Is  pragma  SHARED  supported?  If  so,  are  there  any  restrictions  on  its  use? 

Yes.  There  are  no  documented  restrictions.  [PSEH.  page  7-3] 

7.  Are  there  other  Implementation-dependent  features  supported  such  as  pragmas  or 
attributes? 

There  is  one  Ada/M(44)  defined  attribute  relevant  to  this  area,  namely  PHYSICAL_ADDRESS.  This 
attribute  applies  to  an  object  arxl  yields  the  absolute  address  in  physical  menx>ry  of  the  object. 
However,  in  a  test  case  this  attribute  was  applied  to  a  variable  inside  a  procedure  and  an  error  was 
received.  [PSEH.  page  7-5] 

There  is  an  option  to  the  Ada/M(44)  compiler,  EXECUTIVE,  which  allows  the  user  code  to  run  in  the 
executive  state  of  target,  and  allows  access  to  runtime  support  library  subprograms  and  data.  As 
stated  in  G.l,  this  option  must  be  in  effect  when  using  address  clauses.  [PSEH,  page  9-5] 
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